The role of the operating system (OS) in a computing system is to manage resources in the underlying hardware platform, and expose these resources to the application through software APIs. Examples of resources managed by the OS include virtual and physical memory, CPUs/processor cores (tasks and threads), IO devices (expansion cards) and interrupts (IRQs, ICUs). Within the context of multi-core and many-core processors, it is the OS's responsibility to manage concurrent access to shared resources, both with respect to serialization (e.g., through lock protection) and multiplexing (e.g., scheduling).
Operating systems vary in their design depending on the domain/role that they are being used in. For example, an OS that is used for real-time sensor management is structured differently from an OS that is being used in a desktop PC workstation. A real-time OS (RTOS) incorporates strict resource management with the primary concern of ensuring that computation and IO can be achieved within well-defined temporal bounds. Applications that are deployed on RTOS (e.g., avionics systems, health devices, energy management systems) require extensive analysis of the resources they require, including detailed calculation of CPU (e.g., Worse Case Execution Time—WCET) and memory (e.g. potential stack and heap memory size). That is, successful operation relies upon up-front allocation of resources prior to deployment. When accurate prediction of application resource requirements cannot be achieved, the system designer must over-allocate resources, which can potentially result in waste.
Alternatively, an OS that is functioning within the domain of desktop applications (e.g., Microsoft Windows®, Linux, Oracle Solaris®) manages resources within the OS with the aim of optimizing total throughput of the system. Thus, in such an OS, making guarantees with respect to time is generally not possible—resources are often over-committed and the exact QoS (Quality-of-Service) is not deterministic and therefore cannot be readily predicted.
To summarize this point, traditional OSs are generally designed and optimized for a single-role with concern for either throughput or time. State-of-the-art OSs do not do well managing multiple applications that have different roles—i.e., they are not multi-role.
Another important observation is that single-role OSs cannot be easily adapted to multi-role. This is primarily because of the fundamental differences in the underlying resource management model. In mainstream OSs, such as Linux, Windows® and Solaris®, applications are free to request resources on demand. Furthermore, permission to request resources from the system is implicitly given to all applications—for example, all applications are free to create threads and request allocation of memory.
Monolithic OS designs (e.g., Linux, Windows®, Solaris®) generally provide a two-level security hierarchical; kernel-mode (trusted) and user-mode (untrusted). Program code that is running in kernel-mode has privileges necessary to obtain access to all resources in the system, including interrupts and I/O memory—these can be termed “unsafe resources” since misuse of them can result in total system failure. Alternatively, user-level code generally only has permission to access “safe resources” such as heap memory, threads, processes etc.
Microkernel designs are different from their monolithic counterparts by the fact that access to “unsafe resources” can be given to user-level code. Much of the functionality that traditionally resides in the monolithic kernel (e.g., networking, IO) is moved into the user space. So, a problem that naturally arises is that prior art techniques are inadequate to manage access of a microkernel-based OS and permissions to resources in order to maintain integrity of the system.
With the advent of multi-core and many-core processors, microkernel designs are becoming more significant due to their inherent ability to decouple system services and applications. Particularly, they lend themselves to designs that decentralize system services such as memory management, page-faulting handling, device 10 and so forth. As the compute capability for devices increases (reaching 100-1000 cores in the next 10 years), the potential for devices to perform multi-role functions also become apparent. However, parallel processors bring with them the need to scale the OS so that applications executing on multiple cores can interact with the OS, without interfering with each other, or having performance degraded as a result of forced serialized access. Thus, another problem arises because of the issues in performing resource management scheme that is scalable, and safely meets the needs of multi-core and many-core systems.